Release 10.1A: OpenEdge Deployment:
WebClient Applications
Single sign-on and security caching
WebClient caches each user ID and password entered by the end user and retrieves cached authentication information to access additional objects that require the same user ID and password. When the end user provides authentication information to connect to a server and download the application configuration file or application components, WebClient can cache the authentication information and make it available to the application. Similarly, when the end user, responding to an application prompt, provides authentication information to connect to a server that contains business logic, the application can make the authentication information available to WebClient. By default, WebClient maintains a separate security cache for the application-configuration-file server and the codebase server.
Security caching lets you implement single sign-on, which keeps end users from being prompted multiple times for the same authentication information. Single sign-on is useful when:
- Connecting to the same server multiple times during one session or across multiple sessions; for instance, when application components and business logic for the application are downloaded from the same AppServer. For example, if WebClient downloads application components before the application accesses the business logic, the authentication remains available to the application, and the application can automatically connect to the AppServer to access the business logic. Similarly, if the application accesses the business logic before WebClient downloads application components, the application can make authentication information available to WebClient, and the WebClient can connect to the AppServer to download application components without having to prompt for authentication information.
Note: Authentication information is always stored encrypted.- Connecting to multiple servers that use the same authentication information. Suppose the application configuration file to be downloaded and the application components to be downloaded reside on separate servers but are protected by the same authentication information. You can direct WebClient to make the configuration file’s authentication information available to the application as codebase authorization information (but not the other way around).
Sharing the configuration file cache with the codebase cache works only if the application is launched from a shortcut, not from a Web browser—because in the latter case, the configuration file is downloaded by the Web browser, whose cache WebClient cannot access.
By default, WebClient does not maintain security caches on a particular machine across sessions. To override this default behavior, the end user must specifically request the persistent cache.
You can tell WebClient to disable the persistent cache. If you do so, the end user does not have the option of saving authentication information across sessions, and WebClient deletes the security caches at the end of each WebClient session.
Note: If persistent caching is not disabled, an end user enters authentication information for particular servers, and the end user chooses to cache them persistently, a subsequent end user starting a new WebClient session at the same machine and logging in as the original end user can access those servers without having to re-enter the authentication information.
|
Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |